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Introduction 

When setting out to model and/or simulate a complex mechanical or electrical system, a modeler is 
faced with a vast array of tools, software, equations, algorithms and techniques that may individually or 
in concert aid in the development of the model. Mature requirements and a well understood purpose 
for the model may considerably shrink the field of possible tools and algorithms that will suit the 
modeling solution. Is the model intended to be used in an offline fashion or in real-time? On what 
platform does it need to execute? How long will the model be allowed to run before it outputs the 
desired parameters? What resolution is desired? Do the parameters need to be qualitative or 
quantitative? Is it more important to capture the physics or the function of the system in the model? 
Does the model need to produce simulated data? All these questions and more will drive the selection 
of the appropriate tools and algorithms, but the modeler must be diligent to bear in mind the final 
application throughout the modeling process to ensure the model meets its requirements without 
needless iterations of the design. The purpose of this paper is to describe the considerations and 
techniques used in the process of creating a functional fault model of a liquid hydrogen (LH2) system 
that will be used in a real-time environment to automatically detect and isolate failures. 

Choosing the Right Model for the Application 

Several types of models were considered before the functional fault model was chosen to represent the 
LH2 system. A physics-based model by which live data could be compared to theoretical values is the 
most accurate approach to detecting failures of the system, but the complexity of the LH2 system in all 
its configurations and different stages of loading would make the physics model difficult to verify by LH2 
system experts. If the LH2 system had historical data, the physics model could be compared to past 
data, but the system has not yet been built or operated. Therefore, the physics-based model was not 
chosen due to the lack of verification methods. Another candidate model was a rule-based expert 
system. The intent of the LH2 model is to aid engineers and operators who are monitoring the LH2 
system by providing information about the health of the components and the entire system. An expert 
system would be able to determine the state of the components and system in a reliable, repeatable 



manner assuming that its knowledgebase was comparable to that of the engineer or operator. 

However, the process of translating the engineer's expertise into a model requires a significant amount 
of the engineer's time. Since the LH2 modeling effort was meant to be carried out by a group of non- 
subject matter experts, the rule-based expert system modeling approach was discarded. The functional 
fault model was selected because it allowed the modeling team to review LH2 system design 
documentation independently from the operators and engineers, create a model that resembles the 
schematic diagrams that are familiar to the experts, and have the experts verify the model without a 
large time commitment. The functional fault model captures faults that are known and documented in 
the Failure Mode Effects Analysis (FMEA) and allows real-time software to infer the health of 
components and subsystems based on the effects that are being measured by instrumentation in the 
system. Although the functional fault model has many advantages, one weakness of the technique is 
that the functional fault model only captures known failures. In order to supplement the functional 
fault model, the LH2 fault detection and isolation prototype also includes a data-driven model that 
detects anomalies. The data-driven model was trained on data from a similar LH2 system to create a 
knowledgebase of in-family behavior. After sufficient training on nominal data, the data-driven model 
provides a measure of how closely the data it is monitoring matches the training data. The data-driven 
model is not able to use anomalous scores to isolate to a suspect component or system, but it does 
provide information about which measurements are contributing the most to the anomalous scores so 
that an operator or engineer can be alerted to a potential problem. The data-driven and functional fault 
models are complementary technologies that cover both known and unknown conditions of the system. 

The Modeling Process 

The modeling process was developed with the end-use in mind. The model will be used to automatically 
detect and isolate failures in real-time. Therefore, the model process was purposefully an iterative one 
in which a prototype LH2 model could be developed quickly and with relative accuracy so it could be 
integrated with the real-time software. Having an early model for integrated testing was key to the 
success of the LH2 prototype fault detection and isolation system. The integrated testing helped 
identify shortcomings of the software and the model at an early stage so that issues in the prototype 
could be worked in a timely fashion. The model process that was used for the LH2 system is presented 
in Figure 1. 
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The process begins by establishing a relationship with the system experts and then it becomes iterative 
as the modelers, who are not necessarily subject matter experts, learn more about the LH2 system 



through field visits and interaction with the LH2 system experts. With each successive visit, the LH2 
model gained accuracy and credibility without requiring long periods of time from the experts. 

As the modelers proceeded with the steps in the process, they were diligent to keep the requirements 
of the prototype fault detection and isolation software in mind. The prototype had a few crucial 
requirements and objectives: 

• Model shall have clear mapping back to physical system to aid in initial model validation by 
system experts and maintainability/sustainability by system design engineers 

• Model shall perform isolation during different mission phases and system modes. 

• The model shall be capable of isolating to the failure mode level and another higher level of 
resolution (like the Line Replaceable Unit, or LRU, level). 

• Modeling techniques and practices shall be scalable for a large, integrated model that 
encompasses vehicle systems, ground systems, and facility infrastructure (like power, 
pneumatics, potable water, etc.) 

• Model shall perform fault isolation within 1 second of fault detection. 


Each step in the modeling process was affected by these requirements, including information gathering, 
timing, model complexity, the creation of dynamic flow paths for configuration, telemetry 
considerations, standardization techniques, and interface documentation. Each of these considerations 
will be explained in more detail in the final paper. 

Results 

The result of the focused modeling process was a successful demonstration of the end-to-end system, 
complete with verified model, software, telemetry interface and graphical user interface. The final 
paper will go into more detail about the quality and completeness of the prototype. 

Significance 

The significance of the fault detection and isolation LH2 system prototype is that it provides a 
framework for future modeling efforts and a real-time diagnostic system. The LH2 system model will 
continue to be improved with the addition of more components and failure modes and more testing 
with simulated and/or live data. 



